iT邦幫忙

2024 iThome 鐵人賽

DAY 11
1

今天繼續介紹 使用者驗證的機制

  • 生物識別
  • 硬體驗證 (Hardware Security Module)
  • Single Sign On (SSO)
  • Open Authorization 2.0 (OAuth2)

生物識別

昨天介紹 2FA 時有提到, 透過抽出像是 指紋, 人臉等特徵向量 (去識別化) 儲存於使用者設備, 在登入時就可以比對特徵資訊以驗證使用者身份

硬體驗證

這邊是指 Hardware Token, 機制和我們昨天提過的 TOTP 與 HOTP 類似, 只是昨天是以 "軟體" 為例 (如: Authenticator) 產生一次性密碼

硬體驗證則是透過 "硬體" 產生 密鑰 或 公私鑰
密鑰 可以用來產生 一次性密碼 (類似下面 匯豐 的小精靈)
公私鑰中, 公鑰 會在註冊時傳給服務用以驗證身分, 私鑰 則儲存在硬體設備中

硬體驗證可能包含以下幾個元件 / 功能

  • Near Field Communication (NFC)
  • Hardware Secure Module (HSM)
  • Fast IDentity Online (FIDO)

NFC

允許兩個電子設備在很短的距離內進行無線通訊的技術, 通常包含 讀取器 和 晶片卡

比如支援 NFC 的手機可以透過偵測 自然人憑證 以驗證身份 (報稅時很好用XD), 這時候 手機就是 NFC 讀取器, 自然人憑證則是晶片卡

使用情境: 政府部門身份驗證, 金融交易身份驗證

https://ithelp.ithome.com.tw/upload/images/20240811/20161950puGMi36KPn.jpg

HSM

會有一個專門用來獲取 token 的 "硬體設備" (HSM), 比如筆者之前辦理匯豐銀行戶頭時, 就有配發一台 "小精靈" 負責產生密碼
(記得小精靈自己也要設定 PIN 碼登入, 超級麻煩)

使用情境: 金融服務身份驗證

https://ithelp.ithome.com.tw/upload/images/20240811/20161950TBo5A0rvnb.jpg

FIDO

FIDO 有很多種 Protocols 如 FIDO2, FIDO UAF, FIDO U2F, 每種 Protocols 針對不同的應用情境, 如

  • FIDO U2F: 作為 第二因素驗證, 通常搭配 2FA
  • FIDO UAF: 通常用在 手機 的生物資訊驗證
  • FIDO2: 包括了 WebAuthn (網頁 API) 和 CTAP (溝通 Protocol)

這邊僅簡單介紹 FIDO 驗證流程, 詳細區別請自行查閱~

FIDO 是透過 匹配公私鑰 來驗證使用者身份, 步驟如下

  1. 使用者 註冊網站時插入 驗證設備 如 FIDO2 Security Key
  2. 驗證設備 產生 公私鑰, 將 私鑰 儲存在 驗證設備, 公鑰 傳送給 網站伺服器
  3. 下次登入時, 網站 會發出挑戰 (Challenge)
  4. 使用者 插入 驗證設備
  5. 驗證設備 透過第二因素 驗證使用者身份
  6. 驗證成功後, 驗證設備 取得該網站服務對應的 私鑰, 並用該 私鑰 簽名 網站服務的挑戰 後回傳
  7. 網站 透過收到的 公鑰 驗證該簽名即可通過驗證

https://ithelp.ithome.com.tw/upload/images/20240811/201619508EVIXI30gI.jpg

SSO

看了上面那麼多的驗證方式, 如果我們有多個服務使用 2FA, 每用一個服務使用者就要 輸入帳密, 第二因素驗證 一次
這樣使用者體驗就會很不好

SSO 就是用來解決這個問題的技術, 允許使用者登入一個服務後, 就可以直接使用其他服務而不需重複驗證 :tada:

簡單說明機制

  1. 使用者 登入 網站服務
  2. 網站服務 將使用者請求重新導向到 Identity Provider Service (IPS) 驗證身份
  3. IPS 驗證後產生 Token 給 客戶端
  4. 使用者 使用網站 其他服務 時, 網站服務會透過 Token 驗證使用者身份與權限範圍
  5. 若 Token 驗證通過則 使用者 就不需要再次登入

適用情境: 公司內部服務, 網站有多個服務時

OAuth2

其實 OAuth2 不算是 使用者驗證 的服務, 而是 "授權" 機制, 比較像是將 使用者驗證 外包給第三方服務, 比如透過 Google 帳號, Apple ID, X 帳號, Facebook 登入等等
不過生活中太常見到 OAuth2 的服務了, 而且可以搭配 Open ID Connect (OIDC) 身份驗證機制, 所以還是值得講一下XD

OAuth2 包含以下四個元件

  • Resource Owner
  • Resource Provider
  • Client
  • Authorization Server
    (這邊用原文比較直覺)

假如我們的角色是 Client, 使用者為 Resource Owner, Gmail 負責剩下的 Resource Provider 和 Authorization Server
我們允許使用者透過 Gmail 註冊和登入, 代表我們需要 使用者 "授權" 我們取得 使用者 Gmail 的資訊

  1. 使用者 點擊 使用 Google 帳戶 登入
  2. 我們服務 將請求發給 Gmail Authorization Server
  3. Gmail Authorization Server 請求 使用者 授權, 允許 我們的服務 取得 使用者 Gmail 帳戶的資訊
  4. 使用者 同意授權後, 我們服務 就可以和 Gmail Authorization Server 要一個 Access Token 以便後續取得使用者資訊
  5. Gmail Authorization Server 給 我們服務 Access Token 後, 我們服務 就可以取得 使用者資訊了

常見情境: 遊戲登入 (大部分手遊都有?), 一般網站服務登入 (如 8591)

Reference


上一篇
[Day 10] 使用者驗證 (一)
下一篇
[Day 12] 支付服務 (一)
系列文
30 天 系統設計 學習筆記:建立思考的 SOP30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言